\chapter{System Proposal}
When looking at current LBSs the LIF architecture is the de facto standard for the deployment of cutting-edge LBSs. The LIF architecture is charaterised by:

\begin{itemize}
  \item Usage of the application level MLP protocol
  \item Close coupling to back-end components of the mobile operator
  \item High interoperability irrespective of the underlying air interfaces and positioning methods
  \item Roaming capabilities
  \item Privacy and authentication support
  \item High scalability
\end{itemize}

Particularly in the context of emergency applications these features are crucial for accomplishing the requirements. However, there are LBSs which do not require such highly sophisticated characteristics. An example is a LBS news channel. It differs from emergency services as it requires only low accuracy results whereas emergency services demand on high accuracy. Moreover, emergency services have to function over a whole country and beyond its frontiers while news channel application may only be interesting for a specific area (e.g. tourism area).

Enhanced, \textit{range-based} LDTs like A-GPS, E-OTD, UL-TOA and AOA  include assumptions about device hardware, signal propagation, timing and energy requirements, network makeup, the nature of the environment and time synchronisation of devices. Range-based LDTs estimate point-to-point distances (range) or angles for calculating the position whereas \textit{range-free} LDTs make no assumption about the availability or validity of such information. Concerning to \citet{He2003}, in the context of \textit{Mobile Computing} where hardware and resource limitations prevail, solutions in range-free localisation are being pursued as a cost-effective alternative to more expensive range-based approaches.

Another aspect according to \citet[p. 152]{SchillerVoisard2004} is, that governments have moved in the direction of requiring carriers to become common carriers, opening their wires, fibers and spectrum to other service providers. This initiative opens up a corporate proprietary resource and subsequently enables other companies to compete more freely in the market. 

Comparing the internet and its wired backbone nowadays with PLMNs, one lack is that the former does not provide \textit{fine-grained} location information \citep[chap. 2]{Hjelm2002}. Although research concerning this matter has been made in some \textit{Request For Comments} (RFCs) \citep{RFC1712, RFC1876}, \citeauthor{Hjelm2002} states, that these kinds of information either do not bring the desired results or are static. Relating to this, if terminals were moving, \textit{Domain Name Service} (DNS) records would have to be propagated through the hierarchy of DNS servers. This process would at least take 24 hours to take effect, and is therefore unsuitable for \textit{real-time} services relying on location information \citep{Hjelm2002}. \textit{Indoor positioning systems} on the other hand uses \textit{beacons} (e.g. infrared beacons or radio transmitters) to allow position measurements, but these systems only reached product state in rare cases \citep[p. 192]{SchillerVoisard2004}.

However, location information are fundamentals in back-ends of PLMNs because networks have to know by its own where mobile users are in order to send the data to the serving antenna \citep{Hjelm2002}. \textbf{Comparing with the internet, PLMNs dispose of ``location intelligence''}. Considering this fact, and bringing the potentials of smartphones into the game, a mobile backbone may be born, which brings extended possibilities for the development of mobile services. As a consequence the idea of this work is to exploit these location information, served to MTs, for the purpose of increasing the usability of mobile services. Today's PLMNs continually send status messages through the control channel to participating MTs in the network in order to establish the provision of a permanent mobile service \citep{Hjelm2002}. Some of these status messages contain location information, also known as \textit{cell information}. 

This chapter proposes an approach of how the cellular architecture of PLMNs and its associated cell information can be used to position mobile users. Worth mentioning in this regards is, that the usage of cell information is illegal and not intended for mobile end customers, according to \citet{Heise2005}. Anyway, the ongoing work investigates the potentials of using cell information in the context of loosely coupled, range-free LBSs.

\section{Concept}
On the one hand, mobile network operators store location information in the HLR and VLRs in order to know the serving BTS of mobile users. Data, directed to a specific mobile user, go from the MSC to the according BSC. Dispatching the data by the BSC to the specific BTSs, the data are delivered over the air interface to the MT of the mobile user \citep[p. 223]{SchillerVoisard2004}. Providing coverage of a permanent mobile service requires the deployment of BTSs. These antennas are ideally placed (e.g. rooftops, banks) by NOs. One such BTS is responsible for supplying an area, also named as \textit{cell}, with bidirectional \textit{radio access}, emitted by the antenna. \textbf{Cells itself are uniquely identified by cell information}, defined as follows:

\begin{itemize}
  \item \textit{Cell-id}\\
  Integer assigned by the mobile operator for the identification of a cell
  
  \item \textit{Areacode} (AC)\\
  Integer, incorporating a set of cells,  assigned by the mobile operator
  
  \item \textit{Mobile Network Code} (MNC)\\
  Unique integer for the identification of a PLMN in a country
  
  \item \textit{Mobile Country Code} (MCC)\\
  Worldwide unique integer for the identification of a country in the context of cellular radio (e.g. 232 for Austria)
  
  \item \textit{Short Name}\\
  Unique integer for the identification of a provider in a country
  
  \item \textit{Long Name}\\
  String for the identification of a provider (e.g. 3AT for Drei)
  
  \item \textit{Status}\\
  Integer specifying whether current cell information is valid or not
\end{itemize}

On the other hand, the \textit{Subscriber Identity Module} (SIM), a \textit{smart card} integrated in the MT, also stores this location information \citep[p. 302]{Hjelm2002}. \citeauthor{Hjelm2002} mentions, that network operators rarely want to provide the coordinates of their cells to third parties. \textbf{Anyway, the idea is gaining access to cell information on the SIM card, and continually scanning PLMNs in consideration of the GPS position. This process records cell information, emitted by the antennas of the deployed BTSs in conjunction with the GPS position. The result of this process is a recording of PLMNs cell structure which can be composed for providing LBSs.} Worth mentioning in this regards is, that Austria's government has published information about BTSs deployed in the federal territory in conjunction with the transmitter power, but not any kind of cell information \citep{SenderKataster2006}.

In order to deploy LBSs based on this approach the three following overall tasks are required and discussed in the following sections of this chapter.
\begin{enumerate}
  \item \textit{Cell Information Fetching} (F)
  \item \textit{Cell Information Distribution} (D)
  \item \textit{Cell Information Processing} (P)
\end{enumerate}

This FDP approach is applicable to LBSs which rely on low accuracy results. Due to the demand on cell information these applications may reside at a particular area (e.g. city). Especially in this context there are a lot of application scenarios conceivable, as presented in the first sections of this thesis. One possible application scenario is presented in appendix D. M-Gourmet, a restaurant finder application, implements this concept. However, such niche products can also be used in conjunction with \textit{Context Awareness} to add location considerations based on PLMNs besides other semantical aspects.

\subsection{Cell Information Fetching}
The intention of this process is to fetch cell information from MTs, and subsequently map these information with GPS coordinates. By means of the AT command set \citep{ATCommands1999} the cell information are fetched from the SIM card of the MT. Having these information, the GPS coordinate is requested from a GPS device. 

\textbf{Firstly, these two records together hold the information that a cell is located at a particular GPS position. More important in the context of LBSs is the reverse semantics. Hence if mobile users are booked in a particular cell, the approximate GPS position, depending on the cell size, of the mobile user will be known.}

The reverse engineering of the cell structure can be done with any 3GPP compliant modem such as GSM or UMTS modems and any GPS device providing the required functionalities. The forthcoming section narrows the scope of this process in conjunction with today's placed smartphones to show the process in action.

\subsubsection{Basic Approach}
As mentioned in the introduction, the meaning of smartphones is to combine technologies in a synergistic way. This process exploits the smartphone's capabilities such as interfaces for BT, \textit{Operating System} (OS) functionalities and their APIs in order to record cell information.

It can be done by an application, installed on a smartphone, which provides functionalities for the recording of cell information as well as for BT. As illustrated in figure \ref{Ovierview basic approach fetching cell information}, the application connects via BT to the GPS device. In addition to this, the \textit{Operating System} (OS) of the phone provides interfaces  for fetching cell information. The mobile user cruises around (red line in \ref{Ovierview basic approach fetching cell information}) and the running programme on the MT checks whether handovers occur. If so, the programme takes the origin cell information and the destination cell information in conjunction with the current GPS position and stores these information in a file on the MT.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[width=12.45cm]{graphics/idea}
			\caption[Overview basic approach fetching cell information]{Overview basic approach of fetching cell information.}
			\label{Ovierview basic approach fetching cell information}
		\end{center}
\end{figure}

The \textit{origin cell} is defined as the place from where the mobile user comes when a handover takes place. The area which the user enters is thus described by the \textit{destination cell}. To clarify the details, the following simplified handover XML definition \ref{handoverDefinition} gives some details how cell information can be mapped with GPS coordinates.

\begin{lstlisting}[label=handoverDefinition, caption={Overview recorded cell information.}]
<handovers>
 <handover date="2006-07-13T19:45:20.29">
  <origin>
   <cell id="31109" areacode="11902" mcc="232" mnc="1" status="2"/>
   <signalstrength>82</signalstrength>
  </origin>
  <destination>
   <cell id="2109" areacode="11902" mcc="232" mnc="1" status="2"/>
   <signalstrength>82</signalstrength>
  </destination>
  <gps>
   <longitude>9.88492500</longitude>
   <latitude>47.42963000</latitude>
  </gps>
 </handover>
</handovers>
\end{lstlisting}

\subsection{Cell Information Distribution}
Relating to \citet[p. 153]{SchillerVoisard2004}, standards are important in LBSs to deliver usable products and services. A significant aspect when providing loosely coupled, range-free LBSs based on this approach is the data handling of cell information. When fetching cell data on MTs, they have to be provided in a universal, useable format like \textit{Extensible Markup Language} (XML) in order to guarantee a smooth operation between software components. In effect XML establishes a common ground for the data structure and subsequently makes the data reusable. Despite the heterogeneous LBS environment this can be done by each smartphone supporting the required functionalities regardless of the installed OS.

\begin{figure}[h]
		\begin{center}
	    	\includegraphics[width=12.35cm]{graphics/distribution}
			\caption[Overview cell information distribution]{Overview cell information distribution.}
			\label{Overview cell information distribution}
		\end{center}
\end{figure}

Even though such solutions are probably not designed for collaboration among LBS providers, standardised cell information bring the possibility to distribute these data. Consequently LT providers extend their positioning coverage. Therefore the XML structure of the recorded cell information file has to be standardised for the purpose of exchanging such files among loosely coupled LT providers. This can be done by an XML-Schema to verify that the recorded data are \textit{schema-valid} and \textit{well-formed}. According to \citet[chap. 8]{Stein2002}, the  advantage of XML-Schema comparing to \textit{Document Type Definition} (DTD) is that it permits the exact definition of \textit{namespaces} and \textit{datatypes} defined by the \textit{World Wide Web Consortium} (W3C). 

\noindent
When distributing these \textit{Schema-Instance} files to LBS providers with different back-end systems the XML-Schema makes sure that the delivered data corresponds to the datatypes defined by W3C or to the \textit{complex types} defined in the XML-Schema. Consequently LT Providers adapt their interfaces to the XML-Schema for feeding their systems with handover information.

As illustrated in figure \ref{Overview cell information distribution}, the LT Provider firstly requests the Handovers XML-Schema from the XML-Schema host. The task of the XML-Schema host is to provide the standardised XML-Schemas for LT Providers. If new cell data are available, LT Providers will validate these with the requested XML-Schema before importing new cell data.

\subsection{Cell Information Processing}
Having recorded cell information requires further processing. This section presents the methodology of how these recorded cell information can be used to approximate the position of mobile users.

\noindent
\citet{Bulusu2000} propose the \textit{Centroid Localisation}, which is a range-free, proximity-based, coarse grained localisation algorithm, that uses anchor beacon, containing location information (Xi, Yi), to estimate node positions.  A node estimates its location using the following centroid formula:

$$ (X_e_s_t_,Y_e_s_t_) = (\frac{X_1_ + ... + X_N_}{N}, \frac{Y_1_ + ... + Y_N_}{N}) $$

Relating to \citeauthor{Bulusu2000}, handover data deliver quite similar data than anchor beacons from semantical considerations because they also contain location information, and in fact a handover marks off one cell from another cell. Subsequently the \textit{Cell Borders} (CBs) of \textit{$Cell_A$} can be defined by taking all handovers (cell delimiters), which define \textit{$Cell_A$} as \textit{origin} or \textit{destination} cell ($Cell_A = {CB_1 ... CB_n}$).

Bringing a cell into a more abstract level, it is nothing else than a \textit{polygon}. Analysing the formula by \citeauthor{Bulusu2000}, the problem is that the resulted, estimated coordinate need not be inside the polygon in every case. Moreover, the centroid is influenced by the distribution of the coordinates. For instance, when the majority of coordinates are in the south then the centroid is more in the south than in the north. A more stable figure regarding this effect is the \textit{Center of Gravity} (CoG) \citep{Bourke1988}, given by:

$$ A = \frac{1}{2} \sum_{i=0}^{N-1}(x_iy_i_+_1-x_i_+_1y_i)$$
$$ c_x = \frac{1}{6A}\sum\limits_{i=0}^{N-1}(x_i+x_i_+_1)(x_iy_i_+_1-x_i_+_1y_i)$$
$$ c_y = \frac{1}{6A}\sum\limits_{i=0}^{N-1}(y_i+y_i_+_1)(x_iy_i_+_1-x_i_+_1y_i)$$

Relating to \citeauthor{Bourke1988}, calculating the CoG requires first of all the determination of the \textit{area} A, as presented above. Doing this requires that the \textit{vertices} of the polygon are ordered. \textbf{One side-effect of the ordering is that the \textit{edges} of the polygon must not intersect each other.} The sign of the area A expression can be used in succession to determine the ordering of the vertices. If the sign of area A is positive the ordering of the vertices is \textit{counter-clockwise}, otherwise \textit{clockwise}. 

Bringing this in conjunction with a PLMN cell (polygon) requires the ordering of the cell borders (vertices). As seen before, the result of the fetching process are data about the origin and destination cell information mapped with a GPS position. Anyway, the resulting GPS positions when determining the cell borders need not be ordered.

\begin{figure}[ht]
 \begin{center}
 \subfigure[][]{
  \label{unOrderedCellBorders}
  \includegraphics[width=5.5cm]{graphics/unOrderedCellBorders}}
 \hspace{1cm}
 \subfigure[][]{
  \label{orderedCellBorders}
  \includegraphics[width=5.5cm]{graphics/orderedCellBorders}}
 \caption[Overview (un)ordered cell borders]{This example shows the cell borders (Cell-Id: 1542418; AC: 9000; MNC: 10; MCC: 232; provider: Drei) linked with each other. On the one hand figure \subref{unOrderedCellBorders} visualises all cell borders unordered. The ordering of cell borders is chronological according the date when the handovers were recorded. On the other hand  cell borders in figure \subref{orderedCellBorders} are ordered, and spans a \textit{vector space} (cell area). In succession of the ordering no \textit{intersection} exists in figure \subref{orderedCellBorders}. Subsequently the area and CoG can be calculated, proposed by \citep{Bourke1988}.}
 \label{Overview (un)ordered cell borders}
 \end{center}
\end{figure}

Especially when recording some areas a second time to extend the coverage, a specific handover for instance in the south, fetched the first time, can be chronologically fetched further times after handovers in the north have been fetched in the meantime. It is thereby important to mention, that when speaking of the same handover, the transition of the same origin to the same destination cell is meant, but the GPS position can be different. Hence this handover has to be considered when calculating the CoG because it increases the exact definition of the cell area. An example concerning these matters  is visualised in figure 4.3.

Anyhow, solving this problem requires a \textit{transformation} of the spatial coordinates into a \textit{cartesian} co-ordinate system. This permits  the verification of intersection points between the involved edges. The transformation is based on the \textit{Nautical Mile} (NM). One NM is 1.852 kilometer and defines a \textit{minute of arc} along a great circle (equator) \citep{NauticalMile2006}. It can be therefore used for approximate distances measures, defined as follows:
$$(D_L_o_n, D_L_a_t)=((Lon_A-Lon_B)*60*\cos(Lat_A_V_G)*NM}), ((Lat_A - Lat_B)*60*NM)$$

\noindent
The formula calculates the distance between two spherical coordinates $(A, B)$. The result is the distance in meters for the longitude $(D_L_o_n)$ and latitude $(D_L_a_t)$. When moving towards the poles the longitude minute decreases. This is considered by the cosine of the average latitude $cos(Lat_A_V_G)$ between the coordinates A and B \citep{ExplorerMagazin2000}.

\begin{figure}[ht]
 \begin{center}
 \subfigure[][]{
  \label{transformation1}
  \includegraphics[width=5.5cm]{graphics/transformation1}}
 \hspace{1cm}
 \subfigure[][]{
  \label{transformation2}
  \includegraphics[width=5.5cm]{graphics/transformation2}}
 \end{center}
 \begin{center}
 \subfigure[][]{
  \label{transformation3}
  \includegraphics[width=5.5cm]{graphics/transformation3}}
 \hspace{1cm}
 \subfigure[][]{
  \label{transformation4}
  \includegraphics[width=5.5cm]{graphics/transformation4}}
 \caption[Overview transformation of cell borders]{This illustration shows the linear transformation of spatial coordinates of cell (Cell-Id: 1531918; AC: 9000; MNC: 10; MCC: 232; provider: Drei). Figure \subref{transformation1} shows the starting point. All vertices are not in the correct order for calculating the CoG, and intersections exist. The next step is to transform the cell into a cartesian system. Figure \subref{transformation2} shows the cartesian coordinates in brackets comparing to \subref{transformation1}.  The values of the cartesian coordinates are the distance in meters to the WM (x) and SM (y) coordinate. Figure \subref{transformation3} illustrates the state after ordering the vertices, whereas as figure \subref{transformation4} shows the cell in conjunction with the calculated CoG.}
 \label{Overview transformation of cell borders}
 \end{center}
\end{figure}

The basic idea of this linear transformation is using the distance measures ($D_L_o_n$, $D_L_a_t$) as cartesian coordinates. In fact when transforming cell borders of a cell into a cartesian environment first of all the \textbf{south most spatial} ($SM_S_P_A_T$) and the \textbf{west most spatial} ($WM_S_P_A_T$) cell border is looked up in the set of cell borders ($Cell={CB_1...CB_n})$). Calculating the distances in meters ($(D_L_o_n, D_L_a_t)$) brings the deltas ($\Delta{x,y}$) between these two cell borders. These two coordinates ($SM_S_P_A_T$, $WM_S_P_A_T$) are then transformed into the cartesian system as follows:
$$\Delta x = (Lon_W_M _S_P_A_T - Lon_S_M _S_P_A_T)*60*\cos(Lat_A_V_G)*NM}$$
$$\Delta y = (Lat_S_M _S_P_A_T - Lat_W_M _S_P_A_T)*60*NM$$
$$WM_C_A_R_T (x, y) = (0, \Delta y)  $$
$$SM_C_A_R_T (x, y) = (\Delta x, 0)  $$

As presented above, the whole polygon is transformed in to a positive X and Y range. Hence the origin is P(0,0) in the cartesian co-ordinate system, whereas $WM_C_A_R_T$ and $SM_C_A_R_T$ are used as basis for position the other cell borders in the cartesian environment as follows:
$$CB_C_A_R_T (x) = (Lon_C_B _S_P_A_T - Lon_W_M _S_P_A_T)*60*\cos(Lat_A_V_G)*NM}$$
$$CB_C_A_R_T (y) = (Lat_S_M _S_P_A_T - Lat_C_B _S_P_A_T)*60*NM)$$

Having the transformation done, enables the calculation of intersection points of concerning edges, and the subsequent reordering of CBs in case of intersections. Finally the CoG can be calculated as result of this process.

Summarising the last paragraphs the centroid and CoG are both measures for the approximation of the position concerning mobile users. An important aspect is, that BTSs are probably not located at one of either positions. The reasons concerning this matter are firstly the signal propagation influences. Big obstacles, for example, interfere radio signals, and the position of the BTS can hardly be determined in succession. Secondly, PLMN operators deploy a bundle of direction antennas which emit signals in  specific directions. Hence the position of the BTS is somewhere at the cell boundary located. Anyway, both measures, illustrated in figure 4.5, can be used to determine the position of mobile users.

\begin{figure}[h]
		\begin{left}
	    	\includegraphics[width=8cm]{graphics/map1522218}
			\caption[Overview centroid and CoG]{Overview centroid and CoG \\ (Cell-Id: 1522218; AC: 9000; MNC: 10; MCC: 232; provider: Drei).}
			\label{Overview centroid and CoG}
		\end{left}
\end{figure}

Figure 4.5 compares the centroid (blue dot) and the CoG (green dot). \textbf{The CoG or the centroid position will be returned, if a LBS provider requests the position of a mobile user who is currently booked in this cell.} The deviation in figure 4.5 along the longitude axis is about 15 meters whereas the deviation concerning latitude is more than 110 meters between CoG and centroid. Therefore both measures have been tested. Further information can be looked up in the results (chap. 6)  of this document.

\noindent
In addition of range-free, \textbf{loosely coupled} is often stated in connection with LBSs within this work. As proposed from \citet{He2003}, \textbf{range-free} LDTs do not estimate any point-to-point distances (range). This can be observed in the centroid and CoG localisation. However, \textit{loosely coupled} in the context of this work means the provision of a MPC which does not reside in the back-end of PLMNs. The hybrid MPC uses PLMN information for positioning, but is not tightly coupled with back-end componets such as HLR or VLRs. Reverse engineering reveals first of all the cell structure of PLMNs. After that the idea is to compose these information for offering an independent positioning component.

Knowing the basics of position determination the coming paragraphs propose some use cases on how a MPC can be designed. Providing it for LBS providers or mobile users firstly requires interfaces for importing and merging recorded cell information and secondly for determining the position of mobile users.

\begin{figure}[h]
		\begin{center}
	    	\includegraphics[trim=0.9cm 16.3cm 2cm 1cm, width=14cm, clip=true]{graphics/mpcUseCaseDiagram}
			\caption[Overview use cases hybrid MPC]{Overview use cases.}
			\label{Overview use cases hybrid MPC}
		\end{center}
\end{figure}

As seen in use case diagram 4.6, this hybrid MPC incorporates four basic use cases. The  use cases, \textit{Validate, Import and Merge cell information}, have to do with the processing of cell information. As seen in figure 4.6, actor Cell Supplier has a central role in these processes. Generally he or she is responsible for delivering cell information. On the other side the system must be capable of validating these information. If the information is correct, the system will provide an interface for importing the data, suggested in use case Import cell information.

Another actor involved in the process is the LT Provider. This actor is responsible for the functioning of the system. This party reviews the imported cell information, initiates the (re)calculation of position determination measures such as centroid or CoG. The Merge cell information use case in this regards is separated from the Import cell information use case. This is because the LT provider should be in a position to decide himself when new cell information will be merged, and considered in determination measures. Hence if something goes wrong the LT Provider can \textit{rollback} the merge. 

From the view of Mobile Users the Position request process is significant because this use case provides the location information. The system provides interfaces either for the Mobile User or for the LBS Providers doing this task. Two different approach are possible:
\begin{itemize}
  \item \textit{Indirect Positioning Request}\\
The LBS client programme of the Mobile User will send its \textbf{current cell information}, stored on the SIM card, to the LBS Provider. Arrived at the LBS application server, the LBS Provider takes the received cell information and forwards this information to the MPC (system) of the LT Provider. If the MPC has recorded cell information availaible of the cell where the mobile user currently resides, \textbf{the centroid or the CoG} will be responded as the approximate user position to the LBS Provider. Finally the LBS providers assembles the LBS response based on the user's position and sends the response back to the Mobile User.
  \item \textit{Direct Positioning Request}\\
The Client programme of the Mobile User will directly send its \textbf{current cell information}, stored on the SIM card, to the MPC of the LT Provider. The system checks whether the accuracy measures are available for the cell information directed. If so, the system will send the location information back to the Mobile User.
\end{itemize}

\section{Discussion}
This concept basically uses the actual cell information, stored on the SIM card, for position determination. Hence the expected results correlate with the Cell-Id LDT. Relating to \citet[p. 32]{Hjelm2002}, mobile stations do not only measure the effect needed to connect to the current BTS, but also to those that have lower field strength and therefore are farther away. By means of additional data (RSCP values of neighbouring  BTS with lower signal strength) the accuracy could be improved comparing to the LDT used in the FDP concept.  \citet{Kempii2005} states, that the DCM method uses these further information. The terminal's modem in this regards provides the field strength concerning current and hearable neighbour (generally three) BTSs.

However, as we are looking for range-free schemes the \textit{Approximate Point-In-Triangulation} (APIT) algorithm, proposed by \citet{He2003}, uses  neighbour information as well according to the DCM method. Basically this algorithm performs location estimation by isolation of the environment into triangular  regions. Using some aspects of this scheme in conjunction with range-free, loosely coupled LBSs improves the accuracy comparing with centroid localisation \citep{He2003}. Moreover, a comparison between DCM and APIT results gives further details when developing loosely coupled, range-free LBSs. Such an investigation is not in the scope of this thesis and requires further research.

A completely different approach for improving the accuracy is recording visited cells on MTs. This cells-history can be used to find out motion details concerning mobile users. Observing associations of cells-history may permit further optimisations for the position  determination. Anyway, such an approach can be particularly used when the fact that mobile users are moving is known. 

Nevertheless the FDP concept has some restrictions. Prior to providing LBSs, the cell information has to be known. The recording process takes time and has to be executed in a very careful way. Past experience, when testing the recording process, has shown that most of today's GPS devices do a warm start. This means that these devices store the last known position when shutting down. So when starting the device again it delivers this last position until the first position fix is made. This fact has to be considered carefully because when recording cell information the queried GPS positions have to be valid. \textbf{This method requires the validation and provision of any GPS position in order to bring the expected results}. 

In addition, ongoing infrastructure changes (e.g. deployment of new BTSs) requires continuous recording of cell information. Hence keeping the data up-to-date is a problem when the LBS is deployed over a big area (e.g. country)

Most of today's LDTs lack when orientation comes into the game. This concept does not deal with  orientation specific details. However, when planning  LBSs, and mobile users request map and routing information about \textit{Points of Interest} (POIs), orientation plays an important role. Referring to this when visualising maps on mobile phone screens, compass information can be used to rotate the map in the direction of the user. Facing this example by means of orientation information, the usability can be improved.

In sum this concept provides a first draft for providing loosely coupled, range-free LBSs. \textbf{One big advantage comparing with today's LBS architecture is that this concept permits the integration of various PLMN operators. This can be achieved by recording many networks, and providing for each network positioning over the same hybrid MPC.} In conclusion there is no special interoperability work required between operators, and it abstracts PLMNs to one single positioning infrastructure.
 
\section{Summary}
Introducing into range-free localisation this chapter reflects the concept for providing a loosely-coupled, range-free MPC. Firstly it presents the idea of fetching cell information from PLMNs. Afterwards it shows how these information can be used to provide positioning. Worth mentioning thereby is, that the centroid and CoG are used for the purpose of determining the approximate user position within a cell. Furthermore it mentions the importance of data handling by means of XML. XML therefore constructs a common ground for the definition and validation of cell information. Finally the limitations are revealed to clarify the potentials of this idea.